home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
BBS Toolkit
/
BBS Toolkit.iso
/
programs
/
au512c.zip
/
QWIKER.DOC
< prev
next >
Wrap
Text File
|
1992-03-26
|
62KB
|
1,438 lines
QWiKer version 0.65 - the QWK compatible interface for Auntie
QWiKer is Quicker
SysOp's Manual
Copyright (C) 1991, 1992 by DataWare, Inc.
System Overview 1
License and Warnings 2
System Requirements 2
Setup 3
Step 1 - Create a QWIKER.CFG file 3
Step 2 - Copy the .EXE files 5
Step 3 - Check your Auntie configuration 5
Step 4 - Update your external command list 6
Step 5 - (Optional) Update your synonym list 6
Step 6 - (Optional) Multi-node sysops add CONFIG= 6
Step 7 - (Optional) Netmail 7
Step 8 - (Optional) Setup ALIAS.NAM file 8
System Operation 9
Technical Support 13
Registration 13
Appendix A - Technical layout of files used by QWiKer 14
EXTERNAL.DTA 14
ADDMARK.LST 14
Appendix B - QWK-REP Mail Packet File Formats 15
2QWK Mail Packet Structure Definition 15
MESSAGES.DAT File Format 15
Modification for Netmail packets 16
nnn.NDX File Format 16
CONTROL.DAT File Format 17
BULLETINS Format 18
REP Mail Packet Structure Definitions 19
History 20
i
System Overview System Overview
──────────────────────────────────────────────────────────────────────
Over the last 4 years, offline messaging has become fairly popular in
the BBS community. For those unfamiliar with what offline messaging
is, let me explain. Offline messaging is a way in which users may
download compressed packets of mail (i.e. messages taken from the
BBS's message base) and upload their replies to those messages which
get stored directly in the BBS's message base. There are many
advantages to this.
- First, the users time is freed up. By doing all their messaging
offline, they may spend more time while on the BBS doing other
things.
- The number of users that can get through during the day is
greater because the average amount of time spent on-line is
significantly reduced.
- The users may also spend as much time as they wish reading and
replying to their mail and not have to worry about the BBS timer
running out on them.
- The users can participate in more conferences then would be
reasonable when doing on-line messaging. For BBS's connected to
netmail networks, this is especially important as the number of
conferences the BBS offered can number in the hundreds.
- Long distance callers can lower their long distance bill by doing
all their messaging offline.
Many file formats exist in the BBS community for doing offline
messaging. Most formats are specific to one particular BBS platform.
Such as Teleguard has it's own format and mail reader. GT Powercomm
has it's own. Opus also has it's own. One format that is becoming
very popular among multiple BBS platforms is the QWK-REP standard. It
was invented by Mark (Sparky) Herring about 5 years ago, and is now
available on PCBoard, Wildcat, TriTel, Gap and a few others.
And now with the help of QWiKer, Auntie is included in the list of BBS
platforms that have a QWK-REP compatible mail packet interface. Using
QWiKer, your users will be able to download .QWK compatible mail
packets and upload .REP compatible mail packets. Users will be able
to use their favorite .QWK compatible off-line reader for reading and
replying to their own mail (there are many QWK-REP compatible offline
readers to choose from). They can even control their selection of
message areas spread out across multiple Auntie forums with their mail
reader program. Additionally, QWiKer allows your BBS to act as a QWK-
REP compatible mail HUB for other BBS nodes to call into. However,
the one thing that QWiKer does NOT do, is enable your BBS to be a node
calling another mail HUB for netmail. For this you will need the
QWiKerNet product also produced by Dataware.
QWiKer is also lightning fast in creating .QWK packets. A 386-25Mhz
running under MS-DOS 3.3 can generate an 800 message packet in 1:09
minutes for 2400 bps callers, or 0:30 minutes for 4800 bps and greater
callers and in local mode. A 386SX-16 running under DESQview can
generate the same 800 message packet in 2:12 minutes for 2400 bps baud
callers, or 0:55 minutes for 4800 bps or greater callers and in local
mode.
1
License and Warnings License and Warnings
──────────────────────────────────────────────────────────────────────
You are hereby granted a license to evaluate this software for a
period of sixty (60) days. If on or before this time expires, you
wish to continue using this software, registration of this software as
outlined in the Registration section is required.
You are free to copy and distribute this software PROVIDED:
- No fee is charged for its use, copying or distribution.
- It is not modified in ANY way.
Dataware hereby disclaims all warranties relating to this software,
whether express or implied, including without limitation any implied
warranties of merchantability or fitness for a particular purpose.
Dataware will not be liable for any special, incidental,
consequential, indirect or similar damages due to loss of data or any
other reason, even if Dataware or an agent of Dataware has been
advised of the possibility of such damages. In no event shall
Dataware's liability for any damages ever exceed the price paid for
the license to use software, regardless of the form of the claim. The
person using the software bears all risk as to the quality and
performance of the software.
In other words... I believe this version to be bug and virus free.
However, if this program starts wiping out your files, or otherwise
starts damaging your computer, I will NOT be held responsible for it.
If you do experience any problems with QWiKer, I would very much like
you to drop me a line and I will do my best to fix the problem. See
the section entitled Technical Support on how to reach Dataware.
System Requirements System Requirements
──────────────────────────────────────────────────────────────────────
QWiKer doesn't need much that you haven't already got with your Auntie
BBS. It is recommended (but not required) that you point your
"Temporary path" to as large of a RAM disk as possible, and your "Path
to downloadable files not listed in DIR" to a real hard drive. If
both paths point to the same location (such as a RAM drive), a 1Mb RAM
drive is enough to create a QWK packet containing about 600-700
messages (depending on the size of each message). If the two paths
point to different locations, a 1Mb RAM drive (assuming the "Temporary
path" points to a RAM drive) is enough for about 800-1000 messages.
This version of QWiKer does require Auntie 512 dated 09/19/91 or
later. The program files take 43Kb of disk space and about 96Kb of
memory space to run in, depending on your system configuration.3
2
Setup Setup
──────────────────────────────────────────────────────────────────────
Step 1 - Create a QWIKER.CFG file Step 1 - Create a QWIKER.CFG file
──────────────────────────────────────────────────────────────────────
The first thing you will need to do is create a QWIKER.CFG file. This
file contains configuration information that QWiKer will use during
it's processing, in combination with the information extracted from
the BBSWES.CFG file and the USERS. file. QWIKER.CFG can be created
using your favorite text editor. A QWIKER.CFG file is included in the
package as an example to follow.
The QWIKER.CFG configuration file is a text file that uses the
"KEYWORD=" syntax. Each line starts with a key word (a list of
recognized key words follows), and the definition for the key word
following the "=" character. White space (tabs and space characters)
are permissible to make the file more readable, as well as blank
lines. Case is also unimportant. I use mixed case to make the file
more readable. QWiKer will remove and ignore all white space as it
parses the configuration file, as well as convert everything to upper
case. If you wish to maintain the white space in your definitions,
you must surround the text with quotes. Comments are also allowed in
the configuration file, and are defined as any text following a ";"
character up to the end of the line (a CR/LF pair). Unknown key words
will be ignored, which allows you to copy definitions to/from a
QWiKerNet configuration file.
You MUST have exactly one of each of the following key words: ___________
BBSName= The name of your BBS as will be shown to the user by the
off-line reader program. For example: 'BBSName = "The
Real Batchin' Board"'.
BBSLocation= The City, State that your BBS is located in as will be
shown to the user by the off-line reader program. For
example: 'BBSLocation = "Issaquah, Wa"'.
BBSPhone= The main phone number of your BBS as will be shown to the
user by the off-line reader program. For example:
'BBSPhone = 206-391-2330'.
You may optionally include either or both of the following two key
words:
NetMailFlag= An optional key word that identifies which user flag
(57-64) is used to indicate that the user is a netmail
caller, and to send QWK packets formatted for netmail and
accept REP packets formatted for netmail. For example:
'NetMailFlag = 57'. If this keyword is left out, QWiKer
will never test for netmail callers.
TimeStamp= Controls the timestamp on messages as they are stored in
the message base. Can be set to either "Today" or
"Message". When set to "Today", the message is stored
3
with the systems current date and time. When set to
"Message", the message is stored with the messages
creation date taken from the message header. For example:
'TimeStamp = Today'. If this keyword is left out, the
"Message" setting is assumed.
If you have more then just your main Auntie forum that you want QWiKer
to be able to access, you must include one "Forum n=" definition for
each additional forum QWiKer is to access. Otherwise leave out any
"Forum n=" definitions (or include a commented out "Forum 1"
definition for clarity).
Forum n= Path pointing to one of your BBSWES.CFG files. "n" must
be a number from 2-112. "Forum n" key words are only
needed if you have multiple Auntie forums setup on your
BBS that you want QWiKer to also be able to scan for
messages. For example: 'Forum 2 = D:\AUNTIE\ADULT"
Note: Forum 1 is automatically assumed to be the current sub-
directory. QWiKer will attempt to open up the BBSWES.CFG
file in the current sub-directory, extract the R/W path, the
Node Number, the Node path, and the Temp path and use them
as specified.
Before describing the "Conference n=" keyword definition, a discussion
of what a Conference is, is required. Auntie deals with forums and
message areas within those forums. You can have as many forums as you
wish. You're only limitation is disk space and the desire to set them
up. Message areas are limited to a total of 255 within each forum,
numbered 1-255. Offline readers on the other hand only deal with
conferences. Conferences are limited to a total of 8192, numbered 0-
8191 (however, QWiKer is currently programmed to only handle
conferences numbered 0-1023). What QWiKer does is to map message
areas to conferences.
What you do using the "Conference n=" keyword is to define which
message area of which forum is to map into what conference. You must
have exactly one "Conference n=" definition for each and every message ___________
area you wish your users to have access to via QWiKer. BE VERY
CAREFUL NOT TO MAP THE SAME MESSAGE AREA INTO MULTIPLE CONFERENCES, OR
DEFINE THE SAME CONFERENCE NUMBER MORE THEN ONCE. Cross echoes and
duplicate messages can be the result of one small configuration error.
Conference n= A QWK-REP packet conference number to Auntie message
area mapping assignment. "n" can range from 0-1023.
QWiKer recognizes 4 sub-keys within the "Conference n="
key word definition. They must all be included and each
one must be separated by a "," character, but may be
placed in any order within the definition so long as they
are all placed on the same line following the "Conference
n=" key word. For example: 'Conference 1 = F1, A1, PY,
N"MainBoard"'. Unknown sub-keys are ignored, which allows
you to copy the definitions to/from a QWiKerNet
configuration file. The sub-keys are:
4
Fn - Forum number this conference is assigned to. Must
be 1-n, where n is either 1 or the highest "Forum
n" definition you've declared.
An - Message area this conference is mapped to within
the Forum. Must be 1-255.
PY/PN - Private messages are supported or not supported in
this conference. If configured for PN, any
messages marked as "Private" that QWiKer comes
across will simply be skipped. Note: Private
messages received in REP packets will be stored as
private messages in the message base regardless of
this setting. This setting only affects which
messages will be included in QWK packets.
Nxx - A name for the conference as will be shown to the
user by the off-line reader program. Limited to 10
characters in length and should not contain spaces.
The name should be surrounded by quotes so as to
not be misinterpreted as another key word by
mistake.
Note: It is highly recommended that you skip Conference 0 and
start with Conference 1 mapping into message area 1 of forum
1 wherever possible. This provides a one to one mapping of
conference numbers to message area numbers, which helps in
eliminating confusion by the user and sysop alike.
One you've created the file QWIKER.CFG, you have the choice of putting
it into the same sub-directory where your BBSWES.CFG file is located,
or point to its location by including the "CONFIG=" parameter on the
command line of MAKEQWK and UNPAKREP. How to specify this command
line parameter is explained in step 6 below. Multi-node operators
will appreciate the latter because it allows you to maintain only one
QWIKER.CFG file for all nodes. If QWiKer is unable to locate the
QWIKER.CFG file either where "CONFIG=" points to or in the current
sub-directory it will complain and abort.
Step 2 - Copy the .EXE files Step 2 - Copy the .EXE files
──────────────────────────────────────────────────────────────────────
Place all of the executable files (MAKEQWK.EXE, UNPAKREP.EXE and
QWKCLNUP.EXE) somewhere in your DOS Path. I have mine in D:\, which
is the first entry of my DOS Path list.
Step 3 - Check your Auntie configuration Step 3 - Check your Auntie configuration
──────────────────────────────────────────────────────────────────────
Run the Auntie CONFIG program and under the "Paths and Sub-
directories" menu, make sure your "Path to Downloadable Files Not
Listed in DIR" and your "Temporary path" are set the way you want them
to be. QWiKer builds all its work files in the Temporary path, and
puts the finished QWK packet in the "Not Listed in DIR" path.
5
QWiKer will work best if your Temporary path points to a large RAM
drive (at least 1Mb is recommended in order to handle the larger QWK
packets) and your Path to Downloadable Files Not Listed in DIR points
to a real hard drive. But this is not a required configuration.
Step 4 - Update your external command list Step 4 - Update your external command list
──────────────────────────────────────────────────────────────────────
Add MAKEQWK to your external command list file. It accepts two
command line parameters. The first parameter specifies the maximum
number of messages to put into a QWK packet. This allows you to
prevent a disk full error during processing, as well as control the
maximum packet size a user can download at once. The second parameter
is the maximum number of messages per message area to put into the
packet. When this limit is reached in any message area, QWiKer stops
scanning and proceeds to the next step in generating the QWK packet.
If you do not include either parameter on the command line, it will
default to a limit of 600x200. I recommend that you leave the second
parameter at 200 or less. A few of the off-line readers will actually
crash if more than 200 messages are contained in any single message
area. A MAKEQWK external command line looks like:
qmd, 2, "makeqwk 1500 200",
The "2" in this line is the minimum access level required for the user
to access this command. If the users access level is not 2 or
greater, that user will not be able to access the command. Substitute
the "2" with whatever minimum access level you have chosen for your
users to access the QMD command.
NOTE: MAKEQWK will automatically set the second parameter to unlimited
(i.e. ignore the second parameter) for callers who have their Netmail
flag turned on.
Step 5 - (Optional) Update your synonym list Step 5 - (Optional) Update your synonym list
──────────────────────────────────────────────────────────────────────
Add four lines in your SYN.LST file that read something like:
2/QMD/QMD/Please standby while I generate a QWK packet for you
2/QMU/QMU/
1/QMD//Sorry, your account hasn't been validated for QMD use
1/QMU//Sorry, your account hasn't been validated for QMU use
This provides access level control for both the QMU and QMD commands.
The "2" is the minimum access level required for the user to access
the commands. If the users access level is not 2 or greater, that
user will not be able to access the commands. Substitute the "2" with
whatever minimum access level you have chosen for users to access
QWiKer. Substitute the "1" with one less then the minimum access
required.
Step 6 - (Optional) Multi-node sysops add CONFIG= Step 6 - (Optional) Multi-node sysops add CONFIG=
──────────────────────────────────────────────────────────────────────
If you wish to use the optional "CONFIG=" command line parameter, you
will need to make two changes to the setup thus far. The entry in
your external command file will have to be changed to look like:
6
qmd, 2, "makeqwk 1500 200 /Config=D:\BBS\RO",
The "1500 200" is optional, and will default to 600x200 if not
specified. The "/Config=D:\BBS\RO" specifies the path to where your
QWIKER.CFG file is actually stored. This path can be anything. Your
RO path common to all nodes makes an excellent choice.
The next thing you'll need to do is to modify line number 1136 in your
AUNTEXT. file to also point to your QWIKER.CFG file. Is should look
something like:
UNPAKREP /Config=D:\BBS\RO
CAUTION: DON'T FORGET TO RUN MAKANTXT AFTER MAKING THIS CHANGE, AND
AFTER YOU RECEIVE A NEW AUNTEXT FILE AND REPEATED THE CHANGE IN THE
NEW FILE.
Step 7 - (Optional) Netmail Step 7 - (Optional) Netmail
──────────────────────────────────────────────────────────────────────
If you intend to allow downstream nodes call you for echo mail using
Qnet, Rnet, Tnet, QWiKerNet or any other QWK-REP compatible netmail
software, you will need to create a FLAG5764.TXT file (or add to your
existing FLAG5764.TXT file). The USERSUB program (an Auntie utility)
uses this file to determine what text to display in its information
box when the user flags 57-64 are highlighted.
In this file you must put a netmail flag entry. This file is an
ordinary text file, and uses the following format:
nn, "Flag text"
where nn is the flag number (values 57-64 permitted only), and "Flag
text" is the text that will actually be displayed in the USERSUB
information box when that particular flag number is under the cursor.
Once you have created your FLAG5764.TXT file, place it in your Read
Write Path sub-directory. This is where USERSUB expects to find it.
I have included a sample FLAG5764.TXT file for you to follow. I have
chosen to use flag 57 since it's the first one available to me.
Therefore my entry in FLAG5764.TXT reads:
57, "User is a Netmail caller"
In addition to putting an entry in your FLAG5764.TXT file, you will
also need to make sure there is a "NetMail=" definition line in your
QWIKER.CFG file. On this line you must put the number of the users
flag that QWiKer will look at to determine if the caller is a netmail
caller. The number on this line MUST match the flag number you put on
your netmail entry line within your FLAG5764.TXT file. In my case, I
have the line "NetMail=57" in my QWIKER.CFG file, to match the 57
stored in my FLAG5764.TXT file.
7
Step 8 - (Optional) Setup ALIAS.NAM file Step 8 - (Optional) Setup ALIAS.NAM file
──────────────────────────────────────────────────────────────────────
If you want to allow alias names on your BBS but find that the BBS
network you're connected to doesn't allow them, QWiKer has the ability
to translate the name automatically for you. All you do is create an
ALIAS.NAM file and fill it with the alias to real name translation
definitions. This file is a plain ASCII text file that uses the
format:
ALIAS NAME = REAL NAME
The first name is the alias name that the caller will be using locally
on your board. The second name is the name the alias will be
translated to/from when exported/imported to/from your downstream
netmail nodes calling in. The translation only occurs for those
callers with the netmail flag turned on. So that your regular callers
doing QMD's will see only the alias name in their packets.
8
System Operation System Operation
──────────────────────────────────────────────────────────────────────
Once QWiKer has been properly installed and configured, two new
commands become active and available to the users. These commands are
"QMD" and "QMU" which stand for QwkMail Download and QwkMail Upload.
QMD is used to generate and download a .QWK mail packet (a compressed
file containing messages extracted from the BBS message base). QMU is
used to upload a .REP mail packet (a compressed file containing
replies and new messages typed up by the user while using an offline
reader program) and insert the messages into the BBS message base.
The general sequence of events is:
1. The user first logs on and runs the QMD command downloading a
.QWK packet as the final result.
2. The user then logs off the BBS, possibly after doing other things
since they still have ample system time available for use.
3. Now using any of the available QWK compatible offline readers
(the user can choose from EZ-Reader, SLMR, KingQWK, Session
Manager, Qdeluxe 2, Megamail, WinQWK, and many others) the user
opens up the .QWK packet and reads the messages it contains.
4. The user enters replies to messages and new messages via the
offline reader program, which generates a .REP packet containing
the users messages.
5. Next the user logs back onto the system and by using the QMU
command, uploads the .REP packet which unpacks it and stores the
message(s) into the message base.
If your BBS is part of a netmail network, a user can cause any message
to be stored with the No Echo flag turned on such that the message
will remain local to your BBS and won't be echoed to any other system.
The user accomplishes this by prefacing the subject field with the
characters "NE:". QWiKer triggers off of this and will turn on the No
Echo flag as the message is stored when the first 3 characters match
(case insensitive). It also strips the characters from the subject
field so that other people viewing the message won't see "NE:" in the
subject field.
As of version 0.62, users are able to reset their Hi Message Pointers
automatically, all at once by including the HMP.PTR file in an
uploaded REP packet. What the user does is to extract (PKUNZIP) the
HMP.PTR file from their last good .QWK packet, include it in a .REP
packet (PKZIP) and upload that .REP packet. Upon receipt, QWiKer will
reset all of the users HMP's to be equal to their values AFTER the
download of that specific .QWK packet. It can be the only file in the
.REP packet, or combined with replies as well. The advantage of this
feature is say your last .QWK packet was garbled upon download, or was
accidentally lost altogether. All you have to do now is include a
HMP.PTR file in a .REP upload, and your pointers are automatically
reset such that your next QMD will resend all the messages you lost.
Which messages will actually be included in the QWK packet, and
accepted from a REP packet depends on what access you have granted the
user. If the user has normal access (access level less then 255, and
netmail flag turned off) only public and global messages stored in the
9
users selected message areas will be included in the QWK packet.
Private messages specifically addressed to the user will be included
ONLY IF you have configured PY for the message area the message is
stored in. If the users access level is 255 or it's the actual sysop,
all private messages will be included regardless of how you've
configured the PY/PN setting for the specific message area, and
regardless of the TO field contents. If it's the actual sysop, all
messages marked as deleted will also be included.
When processing a REP packet, QWiKer first checks the packet ID to be
sure the packet belongs to this system. It will only accept packets
with the correct ID. For users with normal access, QWiKer will only
store messages addressed FROM the actual users name and only in
message areas in which the users Allowed Sections flag is turned on.
Private messages in the REP packet will be stored as private in the
message base regardless of the PY/PN setting for the given message
area. If the users access level is 255 or it's the actual sysop,
messages will be stored regardless of the FROM field. If it's the
actual sysop, all messages will be stored regardless of the Allowed
Sections flags.
In the case of a netmail node calling you for mail, the required
sequence is a QMD first, followed by a QMU (if they have a .REP packet
to upload) in the same call. If the order is reversed, the node will
NOT get any mail from your system because their HMP is reset to the
tail end of the message base after the QMU operation.
Each user, prior to running QMD for the first time, should use the SMA
(Set Message Area) command to select which message areas they wish
included in their QWK mail packet. They should do this for all forums
they wish to participate in (to learn more about forums, see the
Auntie Sysop documentation section on doors, pages 93-99). Auntie
turns all message areas ON by default. This would generate an awfully
large QWK mail packet, especially for those systems connected to a
netmail network. They should also use the HMP (High Message Pointer)
command to set a reasonable value. Auntie starts at 0 by default, and
if your system has a reasonable number of messages in its message
base(s), an HMP value of 0 would also generate an awfully large QWK
mail packet. Lastly, the user should verify they have selected a file
transfer protocol they can use. Auntie will automatically
send/receive the mail packets using whatever protocol the user has
configured for without asking.
In detail, when the user enters the command QMD, the program
MAKEQWK.EXE is actually run by Auntie. This program starts by reading
the BBSWES.CFG file (as created by the Auntie program CONFIG.EXE), the
QWIKER.CFG file (as described in the following chapter SETUP), and the
EXTERNAL.DTA file (as generated by Auntie just before shelling out to
MAKEQWK.EXE). For a technical layout of the BBSWES.CFG file, see the
Auntie Sysop documentation pages 160-163. For a technical layout of
the QWIKER.CFG file, see the following chapter entitled SETUP. For a
technical layout of the EXTERNAL.DTA file, see Appendix A. If you are
the sysop of a multi-node system, you can create one QWIKER.CFG file
and point to its location by using the "CONFIG=" switch on the command
line of MAKEQWK (and UNPAKREP) as described below. If this switch is
10
not specified, QWiKer will look for QWIKER.CFG in the current
directory. It will abort if it cannot find it in either place.
QWiKer will also look for both the BBSWES.CFG and EXTERNAL.DTA files
in the current directory and abort if not found.
Since QWiKer is fully aware of the users message area selection etc.,
it requires no further input from the user once started. It does
display status to the user as it progresses in building the QWK packet
so the user can see what's happening and rest assured that the BBS
hasn't hung on them while generating the QWK packet. As it goes
through each forum, one at a time, gathering messages, it displays a
percent completion status to the user at least once per second. Also
as it's gathering the messages, it builds its work files in your
"Temporary Path". At the completion of the message gathering process,
QWiKer shells out to a compression program (it will use whatever
program you have configured as your default compression type,
ARC/ZIP/LZH) to gather all the working files into one compressed .QWK
file stored on your "Path to Downloadable Files Not Listed in DIR".
After the .QWK file has been successfully created, QWiKer deletes its
work files and recreates the file EXTERNAL.DTA, and creates the files
ADDMARK.LST and QWKCLNUP.DAT. In EXTERNAL.DTA, it returns the
MESSAGES, and HMP values to Auntie as described in Appendix A. In
ADDMARK.LST, it returns the full name of the QWK packet that requires
sending (downloading) to the user. In QWKCLNUP.DAT, it stores some
intermediate values that will be used later by the program
QWKCLNUP.EXE. After sending the .QWK file to the user, Auntie
actually runs the program QWKCLNUP.EXE with a parameter of either
SUCCESS or FAILURE to indicate a successful download or an aborted
download (carrier lost of whatever). If the download was successful,
QW2KCLNUP will read the file QWKCLNUP.DAT and update the users HMP
values in all the forums appropriately and delete the QWKCLNUP.DAT
file. If however the download failed, QWKCLNUP will simply delete the
QWKCLNUP.DAT file. This method enables 2 features. First, if the
download of the QWK packet fails, the users HMP settings are not
modified such that they can call back and execute another QMD to
receive the mail they're missing. Secondly, after a successful
download, all the HMP's are properly updated, and the user can do
another back to back QMD to obtain any remaining messages (assuming
the first packet reached one of the size limits).
When the user enters the QMU command, Auntie starts by going into
receive mode expecting to be sent a .REP file. Once received, Auntie
will automatically test the file for integrity using the appropriate
compression program. After the file has passed the integrity test,
the file is moved from the -TU directory into the UL path. Then
Auntie runs the program UNPAKREP.EXE. Just like MAKEQWK.EXE, this
program starts by reading the BBSWES.CFG file, the QWIKER.CFG file,
and the EXTERNAL.DTA file. It then unpacks the .REP file, begins
reading messages from it, storing them in the message base one at a
time as it goes along. As each message is stored, a status line is
shown to the user so they know what messages were actually accepted
and stored. If the user is a netmail caller (i.e. their netmail flag
is turned on), their HMP values will be updated such that they won't
be sent their QMU'd messages as a part of their next QMD (this is why
netmail nodes MUST perform a QMD followed by a QMU specifically in
11
that order). Lastly, it erases and re-creates the EXTERNAL.DTA file,
and returns the PML and HMP values to Auntie as described in Appendix
A.
12
Technical Support Technical Support
──────────────────────────────────────────────────────────────────────
If you have any questions or problems regarding QWiKer or any other
Dataware product, please call our office for assistance. Our office
hours are Monday through Friday, 9:30am-5:30pm Pacific time. You can
also leave a message or pick up the latest versions on our 24-hour BBS
named "The Real Batchin' Board". You may also mail your comments and
questions to the Dataware office. The Dataware address and phone
numbers are as follows:
Dataware, Inc.
Suite 2571
1420 NW Gilman Boulevard
Issaquah, Wa. 98027-7001
Voice (9:30am to 5:30pm PT): (206) 391-9333
The Real Batchin' Board BBS (available 24 hours): (206) 391-2330
You can also reach us via the following:
Auntie Support Forum BBS (available 24 hours): (510) 938-5836
Intelec Network Offline Conference
Registration Registration
──────────────────────────────────────────────────────────────────────
If you find that QWiKer is useful to you, you can become a registered
user. As a registered user, you will receive a diskette with the
final version 1.00 (the final production release) on it when
available. You will also automatically receive, when available, a
free upgrade to QWiKer version 1.10. The current registration fees
are as follows:
QWiKer on 5¼" or 3½" Diskette (please specify) $ 50
Discount if you've registered QWiKerNet at full price $(15)
Laser Printed Manual $ 3
Ups Ground $ 3
Ups Second Day Air $ 6
Ups Next Day Air $ 12
All Over-seas Shipping $ 6
Washington residents add 8.2% sales tax to the total
As a bonus, you may register both QWiKer and QWiKerNet for one low fee
of $75 instead of the normal full combined price of $90.
13
Appendix A - Technical layout of files used by QWiKer Appendix A - Technical layout of files used by QWiKer
──────────────────────────────────────────────────────────────────────
EXTERNAL.DTA EXTERNAL.DTA
EXTERNAL.DTA is a line oriented plain text file created by Auntie in
the default sub-directory. It contains necessary information about
the users current settings that QWiKer requires for proper processing.
Auntie creates it in the following format:
Line 1: An integer in the range 1-32767 indicating the record number
in the USERS. file that belongs to the caller.
Line 2: The caller's logon name. May be up to 31 characters in
length.
Line 3: Will contain either "Local" if in local mode or the DCE
(modem-to-modem) speed of the caller (300/1200/2400/9600/
14400/19200/etc).
Line 4: Either an "E" for even parity or an "N" for no parity
Line 5: The caller's (or SysOp's) High Message Pointer (1-9999999).
Line 6: The caller's (or SysOp's) ZIPM counter number (0-99).
Line 7: The caller's (or SysOp's) SSO setting. 0 equates to off. A
non-zero value indicates an SSO setting for that specific
message section (1-255).
When MAKEQWK has finished its processing, it erases the contents of
this file and stores two new lines in it. These lines are as follows:
Line 1: HMP n. Where n is the highest message number (1-9999999) from
the main forum (forum 1) that was included in the mail packet.
Line 2: MESSAGES n. Where n is the total number of messages (1-32767)
put into the mail packet.
When UNPAKREP has finished it's processing, it to erases the contents
of this file and stores two new lines in it. These lines are as
follows:
Line 1: PML n. Where n is the total number of Personal Messages Left
(1-32767).
Line 2: HMP n. Where n is the highest message number (1-9999999) from
the main forum (forum 1) that was included in the mail packet.
This line is included ONLY IF the caller is a netmail caller
(the netmail flag is turned on in the users account).
ADDMARK.LST ADDMARK.LST
Another file that MAKEQWK creates after it has finished processing is
ADDMARK.LST. This file is a plain ASCII text file, in which each line
is the name of a file that requires sending to the user. The first
line will always read "xxxxxnn.QWK". This is the name of the QWK file
actually generated and ready to be downloaded by the user. Additional
lines will be of files requested for download by the user via a mail
door message.
14
Appendix B - QWK-REP Mail Packet File Formats Appendix B - QWK-REP Mail Packet File Formats
──────────────────────────────────────────────────────────────────────
QWK Mail Packet Structure Definition QWK Mail Packet Structure Definition
This appendix thoroughly describes the structure of the QWK-REP mail
packets that have become so very popular among various bulletin
boards. This information is copyright 1991 by Dataware, Inc., and was
gathered from many other documents, as well as experimentation.
Dataware, Inc. gratefully acknowledges Mark (Sparky) Herring for
developing the original Qmail door which utilizes this structure.
.QWK packets are composed of 3 file formats, CONTROL.DAT,
MESSAGES.DAT, and nnn.NDX files. Each of the file formats are
described in the following text.
MESSAGES.DAT File Format MESSAGES.DAT File Format
This file contains all of the messages in the packet, along with their
headers. It is composed of 128 byte records. The very first record
is always the mail door copyright message. The second record is the
message header for the first message in the packet. Immediately
following this record, are all the records for the first message. The
next record following the message records is the message header for
the 2nd message in the packet. Again followed by the records for the
message itself. This layout (header record/message records) continues
for all messages in the packet, at which point this file simply ends
(except for netmail packets as described below). NOTE: there is no
indication of how many messages are in the packet. The only way to
determine this information is to scan the packet and actually count
the number of messages.
The 128 byte message headers have the following structure. All ASCII
fields are left aligned and padded on the right with spaces:
Offset Length Description
────── ────── ──────────────────────────────────────────────────
1 1 Message status flag:
' ' = public
'-' = public and read
'*' = private
'+' = private and read
2 7 Message Number in ASCII
9 8 Date (mm-dd-yy) in ASCII
17 5 Time (hh:mm) in ASCII
22 25 To
47 25 From
72 25 Subject
97 12 Password (always filled with spaces)
109 8 Parent (reference) message number in ASCII
117 6 Number of 128 byte blocks in message (including
the header) in ASCII. Minimum value is 2
123 1 Message alive status:
'ß' = Message is alive
15
'Γ' = Message has been marked as "Killed" or Deleted
124 1 Lsb of conference number (0-255)
125 1 Msb of conference number in new format for > 256
conferences. Space in the original standard.
126 3 Space filled
The message records are all 128 bytes each, with a 'π' character used
as a new line separator. The last line of the message text is padded
with spaces as required to fill out the 128 byte record size
requirement.
Modification for Netmail packets Modification for Netmail packets
In order to provide some form of security and prevent sysops from
"stealing" the message base of another BBS, a set of net status flags
are added to the QWK packets which indicate which conferences are
enabled for netmail and which aren't. Most QWK-REP mail doors are
configurable on a user by user basis as to which conferences the user
has been granted netmail access. If the user has no netmail access,
or else the mail door does not support netmail, these flags will be
missing from the QWK packet.
These flags are stored as additional 128 byte records appended to the
end of the MESSAGES.DAT file. Each byte in each record contains one
flag for one specific conference. If the flag is non-zero, netmail is
permitted for that specific conference number. If the flag is zero,
netmail is NOT permitted for that specific conference number.
The flags are positional sensitive so that the very last 128 byte
record in the MESSAGES.DAT file contains flags for conferences 0-127,
sequentially. If additional flags are required for more conferences,
additional 128 byte records will be stored preceding the last one. So
the second to last record contains flags for conferences 128-255. The
third to last record contains flags for conferences 256-383. And so
on for as many conferences exist that require netmail flags.
In addition to net status flags, netmail QWK packets generally do not
include any nnn.NDX files as they are not required nor used by the
netmail importing software. There are no changes to the REP packets
to support netmail.
nnn.NDX File Format nnn.NDX File Format
This file contains an array of 5 byte pointers to the message headers
stored in the MESSAGES.DAT file. There can be many nnn.NDX files, one
for each conference that has been included in the packet. Conference
0 would be indicated by the existence of the file 000.NDX. Conference
1 by 001.NDX, conference 10 by 010.NDX, conference 200 by 200.NDX,
etc. Only conferences which have actual messages included in the
packet will have an nnn.NDX file included for them. There may also be
a PERSONAL.NDX file included in the packet. This file follows the
same format as the nnn.NDX file, but points to all messages included
in the packet that are addressed TO the user. Each pointer in the
nnn.NDX files has the following structure:
16
Offset Length Description
────── ────── ─────────────────────────────────────────────────────
1 4 MSBIN floating point format of the Record number of
the message header in the MESSAGES.DAT file. This
field is 1 based, and since the very first record is a
mail door info record, the first record will always be
2 in this field. NOTE: Be careful with this entry.
It does NOT follow the IEEE standard that MS has
switched to for their standard. MSC 6.0 has 2
functions for converting between IEEE and MSBIN
format. But all calculations are done in the IEEE
format. And in the latest QBasic you must explicitly
tell it to use the old MSBIN format instead of the
default IEEE format.
5 1 Conference number of this message. Recommended to
just ignore this byte, and use the Conference number
in the message header for > 256 conference support.
CONTROL.DAT File Format CONTROL.DAT File Format
This file is an ASCII text file that contains information about the
BBS the packet was downloaded from, and about all the conferences the
user has access to. Each line has a specific purpose. The lines are
defined as follows:
Line 1: The full name of the BBS.
Line 2: The City,State where the BBS is located.
Line 3: The primary phone number of the BBS.
Line 4: The SysOps name followed by ", Sysop" on the same line.
Line 5: The 5 digit serial number of the mail door followed by the
base name of the QWK packet. These two fields are separated
by a comma.
Line 6: The Date & Time the packet was generated. Stored in the
format "MM-DD-YYYY,HH:MM:SS".
Line 7: The name of the user the packet belongs to.
Line 8: Always an empty line.
Line 9-10: A single "0" on each line (purpose unknown at this
time)
Line 11: The number of conference descriptions following, minus 1.
Line 12: The conference number of the first conference description.
Line 13: The 10 character maximum conference name of the first
conference.
Line 14: The conference number of the second conference description.
Line 15: The 10 character maximum conference name of the second
conference.
.
.
.
.
Line n: The conference number of the last conference description.
Line n+1: The 10 character maximum conference name of the last
conference.
Line n+2: The filename of the optional logon file to display.
Line n+3: The filename of the optional news file to display.
Line n+4: The filename of the optional logoff file to display.
17
BULLETINS Format BULLETINS Format
If bulletins are included in the packet, the names of the bulletin
files must follow the format "BLT-ccc.nnn". Where "ccc" is the
conference number the bulletin is associated with (0-999) and "nnn" is
the number of the bulletin (1-999).
18
REP Mail Packet Structure Definitions REP Mail Packet Structure Definitions
.REP packets consist of only 1 file format. The base name of this
file is always taken from the second parameter of line 5 in the
CONTROL.DAT file. The extension is always .MSG. Thus if the sysop
has configured his mail door for a base name of BATCHN, the filename
of the file in the .REP packet will be BATCHN.MSG. In addition, the
base name of the .REP packet uses this same CONTROL.DAT parameter.
Thus the .REP packet would be named BATCHN.REP.
The format of the .MSG file is nearly identical to that of the
MESSAGES.DAT file. The major difference is in the first 128 byte
record. The first 8 characters always contain the base name of the
mail packet, padded with spaces as necessary to fill out the record.
Thus continuing our example, the first 8 characters would be
"BATCHN ", and the rest of the 128 byte record would be filled with
spaces.
The remainder of the packet follows the exact same 128 byte record
format as used for MESSAGES.DAT (as described above) with the
following variances:
1) The conference number is stored in ASCII format in place of the
message number
2) The conference number field may be filled with spaces or the real
conference number.
19
History History
──────────────────────────────────────────────────────────────────────
v0.60 07/29/91 - Completely restructured the configuration file format
in preparation for scanning multiple forums at once,
placing messages in the appropriate conference.
- Eliminated the use of the BBSECT.NAM file in favor of
the conference name now being specified in the
configuration file.
- Scan multiple forums, gathering new messages, and
sorting them into the correct conference number
assignment.
- Include Deleted messages in QWK packet if user is
sysop or is a 255er.
- Fixed bug in which messages in section 64 would
always be included in the QWK packet.
- Do not include GLOBAL messages in QWK packets for
netmail callers.
- Optimized code for improved scanning speed when
creating a QWK packet.
- When configured to use PKZIP, include the "-es"
command line switch to force it to use the much
faster Shrinking method when caller is at 4800 or
greater, or is local. These users can generally
transfer data faster then the additional compression
saved by the use of Imploding.
- Fixed bug which would cause MAKEQWK to sometimes not
read the command line parameters properly.
- Store the checksum of the TO field for the new Auntie
v512 MSGTO.IND file.
- Skip over any message contained in a REP packet that
are addressed "TO: QWIKER". These are the
ADD/DROP/RESET commands.
- Fixed bug where node number was random for single
node setups.
v0.61 08/20/91 - Added communication routines so that QWiKer can talk
to the user through the modem.
- Added "/CONFIG=" command line switch to point to the
QWIKER.CFG file.
- Make Forum 1 an automatically implied forum as the
current sub-directory. A result of this is "Forum 1"
must NOT be defined in the QWIKER.CFG file.
- Detect loss of carrier during MAKEQWK and abort the
operation.
- Present more information to the user, including
number of messages packed, number of personal
messages found, and what messages were imported along
with where.
- Fixed bug in which messages stored when configured
for "Today" were stored as 1971 messages instead of
1991
v0.62 12/04/91 - Modified to match the new file formats of 5.12.
- Corrected Checksum generator when importing messages
via QMU.
20
- Added the QWKCLNUP program to update the HMP values
only after a successful QWK packet download.
- Fixed a bug in which the names of conferences 128-255
were not being included in the CONTROL.DAT file.
- Handle importing of messages into message base with
>32767 records
- Pay attention to all 32 bytes of Allowed and Selected
sections. Not just the first 8.
- Added support of a HMP.PTR file to be used for
resetting the HMP's of all the forums at once.
- Correctly detect the conference number in a .REP
packet as stored by the program WinQWK.
- Replace ARC with ARJ support.
- Open QWIKER.CFG and BBSWES.CFG files in share
compatibility mode.
- Use a 16 bit counter instead of an 8 bit counter for
the number of messages/conference count.
- Handle case where users HMP is 0.
- Do not delete "*.QWK" upon startup. Delete the
specific .QWK file created during the QWKCLNUP phase
instead.
- In the event of a .QWK filename conflict between
multiple nodes, increment the Counter until the
conflict is resolved.
v0.63 01/09/92 - Handle messages up to 12800 bytes in length.
v0.64 02/01/92 - Fixed bug where the ALLOWED flags for message areas
65-255 were not being read properly causing some
messages to not be stored during a QMU.
- Fixed bug where "Not Echoed" and "Global" messages
were being sent to netmail callers.
v0.65 03/25/92 - Added support for an alias name table called
ALIAS.NAM.
- Accept SSO sections that are allowed, but not
selected.
- Bump "Messages Left" counter in each forum during a
QMU.
- Append correct number of NetStatus flags based on
highest conference number defined.
- Include a SESSION.TXT file in the QWK packet listing
the number of messages in each conference included in
the packet.
- Do not display the list showing the number of
messages included for each conference when the caller
is a Netmail caller.
- Public/Read messages were being stored as Private
messages by mistake. Fixed.
- If Auntie is configured to readdress messages
"TO:SYSOP", messages stored as such will have the
sysops configured name put in the TO field instead.
- Trap the DOS console and display all text in a DOS
window and copy it out the modem port to the user.
21